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Abstract 

The implementation of an integrated system health management (ISHM) capability is fundamentally 
linked to the management of data, information, and knowledge (DlaK) with the purposeful objective of 
determining the health of a system. It is akin to having a team of experts who are all individually and 
collectively observing and analyzing a complex system, and communicating effectively with each other in 
order to arrive at an accurate and reliable assessment of its health. In this paper, concepts, procedures, 
and approaches are presented as a foundation for implementing an intelligent systems-relevant ISHM 
capability. The capability stresses integration of DlaK from all elements of a system. Both ground-based 
(remote) and on-board ISHM capabilities are compared and contrasted. The information presented is 
the result of many years of research, development, and maturation of technologies, and of prototype 
implementations in operational systems. 

Purpose /Motivation 

In this paper, Integrated Systems Health Management (ISHM) is presented as an enabling technology for 
intelligent systems. To that end, a variety of intelligent systems-relevant ISHM topics are addressed and 
examples presented. The information presented should provide the reader with an understanding of 
current research and challenges that are relevant to ISHM as one element of an intelligent system. 

ISHM has been defined from many perspectives. Here it is defined as a capability that is achieved by 
integrating data, information, and knowledge (DlaK) that might be distributed throughout the system 
elements (which inherently implies the capability to manage DlaK associated with distributed sub- 
systems). DlaK must be available to any element of a system at the right time and in accordance with a 
meaningful context. ISHM Functional Capability Level (FCL) is measured by how well a system performs 
the following functions: (1) detect anomalies, (2) diagnose causes, (3) predict future anomalies/failures, 
and (4) provide the user with an integrated awareness about the condition of important elements of the 
system as a means of guiding user decisions. 

Scope/Organization 

The paper opens with a glossary of relevant ISHM terms. Because the development of an ISHM system is 
interdisciplinary by nature, terminology is seldom consistently used. It is, therefore important to define 
the basic terminology that will be used to support ensuing discussions. The paper then describes a 
process for developing an ISHM capability - standards, qualitative failure models, and optimization of 
sensor selection and placement are addressed as a part of the development process. Next, an ISHM 
knowledge domain model is defined that is particularly suited to intelligent systems. This model is based 
on Data, Information, and Knowledge (DlaK) of the system. This knowledge model is used as the basis 
for Intelligent ISHM architectures for ground-based (remote) and onboard flight (manned and 
unmanned) systems. Elements (e.g., diagnostics, prognostics) of the architectures are subsequently 
described in some detail with examples of specific algorithmic approaches and results. The topic then 
turns to the system engineering process where the role of ISHM and benefits to the system engineering 
process are addressed. The chapter closes with brief discussion on impact of ISHM on an intelligent 
control system and opportunities for advances in verification and validation of complex ISHM systems. 
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Nomenclature 


CSG 

= 

Chemical Steam Generator 

DIaK 

= 

Data, Information, and Knowledge 

DIaKA 

= 

Data, Information, and Knowledge Architecture 

FCL 

= 

Functional Capability Level 

FET 

- 

Field Effect Transistor 

FMEA 

= 

Failure Modes and Effects Analysis 

GN 

= 

Gaseous Nitrogen 

IMBT 

= 

ISHM Model Building Toolkit 

IPA 


Isopropyl Alcohol 

IS 

= 

Intelligent Sensor 

ISHM 

= 

Integrated Systems Health Management 

ISHM-DM 

= 

ISHM Domain Model 

KSC 

= 

Kennedy Space Center 

LC-20 

= 

Launch Complex 20 

LOX 

= 

Liquid Oxygen 

NASA 


National Aeronautics and Space Administration 

NCAP 

= 

Network Capable Application Processor 

OSA-CBM 

= 

Open Systems Architecture for Condition-Based Maintenance 

RCA 

= 

Root Cause Analysis 

RETS 

- 

Rocket Engine Test Stand 

S4 

= 

Systematic Sensor Selection Strategy 

SS 

= 

Smart Sensor 

S&As 

= 

Sensors and Actuators 

SS&As 

= 

Smart Sensors and Actuators 

ssc 

= 

Stennis Space Center 

STE 

= 

Special Test Equipment 

TCP/IP 

= 

Transmission Control Protocol/Intemet Protocol 

TEDS 

= 

Transducer Electronic Data Sheet 

TIM 

= 

Transducer Interface Module 

VISE 

= 

Virtual Intelligent Sensor Environment 


I. Abstract 

T He implementation of an integrated system health management (ISHM) capability is fundamentally linked to 
the management of data, information, and knowledge (DIaK) with the purposeful objective of determining the 
health of a system. Management implies storage, distribution, sharing, maintenance, processing, reasoning, and 
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presentation. ISHM is akin to having a team of experts who are all individually and collectively observing and 
analyzing a complex system, and communicating effectively with each other in order to arrive at an accurate and 
reliable assessment of its health. In this paper, concepts, procedures, and approaches are presented as a foundation 
for implementing an intelligent systems-relevant ISHM capability. The capability stresses integration of DIaK from 
all elements of a system, emphasizing an advance toward an on-board, autonomous capability. Both ground-based 
(remote) and on-board ISHM capabilities are compared and contrasted. The information presented is the result of 
many years of research, development, and maturation of technologies, and of prototype implementations in 
operational systems. 


II. Introduction 

In this paper, Integrated Systems Health Management (ISHM) is presented as an enabling discipline/technology 
area for intelligent systems, as well as a capability that embodies “intelligence” in itself. To that end, a variety of 
intelligent systems-relevant ISHM topics are addressed and examples presented. The information presented should 
provide the reader with an understanding of current research and challenges that are relevant to ISHM as a core 
capability of an intelligent system. 

ISHM has been defined from many perspectives. Here it is defined as a capability that is achieved by integrating 
data, information, and knowledge (DIaK) that is conceptually and/or physically distributed throughout the system 
elements (which inherently implies the capability to manage DIaK associated with distributed sub-systems). The 
term DIaK management encompasses contextual and timely storage, distribution, sharing, maintenance, processing, 
reasoning, and presentation. This paradigm implies that DIaK must be available to any element of a system at the 
right time and in accordance with a meaningful context. ISHM Functional Capability Level (FCL) is measured by 
how well a system performs the following functions: (1) detect anomalies, (2) diagnose causes, (3) predict future 
anomalies/failures, (4) enable efficient integration and execution of all phases of the life-cycle of a system from a 
systems engineering perspective, and (5) provide the user with an integrated awareness about the condition of 
important elements of the system as a means of guiding user decisions. 

The paper is organized as follows: Section III describes core areas of ISHM capability development, including 
standards and related architectures, the ISHM knowledge model, software tools, intelligent sensors and components, 
and sensor selection and placement. Section IV describes ISHM in the context of systems design, integration, and 
engineering. Section V describes briefly controls for ISHM-Enabled systems. Section VI describes briefly 
opportunities for advances in validation and verification of ISHM systems. Section VII provides conclusions. 

III. ISHM Capability Development 

ISHM capability is currently done, but for complex systems, it involves many people, it is very costly and 
difficult to improve with time and use, it involves minimal integration of DIaK across the system, it is not 
comprehensive (does not include all elements of a system or much DIaK about the system), and it is not continuous 
(a people-based system is generally not vigilant 24 hours a day, every day). The following sections describe what is 
needed to achieve ISHM capability that is mainly on-board the system, affordable and evolutionary throughout the 
life of the system, integrates DIaK across the system, is continuous, and is comprehensive. In order to make this 
possible, it is necessary that the ISHM capability must incorporate a knowledge-based approach, and hence embody 
“intelligence.” 

A. Standards for ISHM Implementation 

The development of an ISHM capability requires the use of models (knowledge) applied to information and data 
associated with various elements that make up a system. Here, the term “model” is used in the broadest sense as it 
may include qualitative (e.g. heuruistics), analytic, statistical, fuzzy-logic, classic logic, artificial neural network and 
other types of models. Use of models is enabled by management of DIaK, encompassing storage, distribution, 
sharing, maintenance, processing, reasoning, and presentation. In order to make this possible in a generic manner, 
meaning not for a specific application; standards must be established so that DIaK can be managed in a plug&play 
and interoperable manner. 

Standards for ISHM must be at a high enough layer in the infrastructure so that they are largely independent of the 
physical (e.g. Ethernet) and transmission (e.g. TCP/IP) layers. Example standards for ISHM include the IEEE 1451 
family of standards for smart sensors and actuators, the Open Systems Architecture for Condition-Based 
Maintenance (OSA-CBM) standard, and the Machine Information Management Open Standards Alliance 
(MIMOSA). These standards are sufficiently abstracted so that they can be implemented as part of any physical or 
transmission architecture. 
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1. IEEE 1451 Family of Standards for Smart Sensors and Actuators (SS&A) 

The IEEE 1451 family of standards was developed by government and private entities under the leadership of 
the National Institute of Standards and Technology (NIST). Reference XX (book chapter) provides a summary of 
the standards and their use. In creating these standards, the objective was to standardize DIaK associated with 
sensors and actuators (S&As). The standards are described as a family because, as evidenced from the quote in the 
following paragraph, they address various elements and functions of Smart Sensors and Actuators (SS&As). The 
notion is that SS&As must incorporate DIaK related to their functionality and provide their DIaK, via a 
communications network, to other systems or functions that use and manage S&As. 

“The IEEE (Institute of Electrical and Electronics Engineers) 1451 smart transducer interface standards 
provide the common interface and enabling technology for the connectivity of transducers to microprocessors, 
control and field networks, and data acquisition and instrumentation systems. The standardized TEDS specified by 
IEEE 1451.2 allows the self-description of sensors and the interfaces provide a standardized mechanism to facilitate 
the plug and play of sensors to networks. The network-independent smart transducer object model defined by IEEE 
1451.1 allows sensor manufacturers to support multiple networks and protocols. Thus, transducer-to-network 
interoperability is on the horizon. The inclusion ofP1451.3 and P1451.4 to the family of 1451 standards will meet 
the needs of the analog transducer users for high-speed applications. In the long run, transducer vendors and users, 
system integrators and network providers can all benefit from the IEEE 1451 interface standards [1].” 

The most common physical architectures for systems are bus-based multi-drop configurations. Figure 1 shows 
configurations and implementation of IEEE 1451 standard, and a short summary is provided below. The standards 
are still being modified, but the intent here is to provide a sense of how the standards can be used to enable 
interoperability and plug&play capability with networked transducers with embedded information (hence, smart 
transducers). 

IEEE PI 45 1.0 defines a set of common commands, common operations, and Transducer Electronic Data Sheet 
(TEDS) for the family of IEEE 1451 standards. The commands allow communication with sensors or actuators in 
IEEE 1451 -based wired and wireless networks. The functionality is independent of the physical communications 
media and the network node called Network Capable Application Processor (NCAP). 

IEEE 1451.1 defines a common object model describing the behavior of smart transducers (sensor and actuators). It 
defines the communication models used for the standard, which include the client-server and publish-subscribe 
models. Application software based on IEEE 1451; running in the NCAP, communicate with transducers through 
any physical layer standards as needed for a particular application. The standard enables communications among 
NCAPs and to higher level systems, in a network neutral manner. 

IEEE 1451.2 defines transducers-to-NCAP interface and TEDS for a point-to-point configuration. Transducers are 
part of a Transducer Interface Module (TIM). The original standard describes a communication layer based on 
enhanced SPI (Serial Peripheral Interface) with additional HW lines for flow control and timing. 

IEEE 1451.3 defines a transducer-to-NCAP interface and TEDS for multi-drop transducers using a distributed 
communications architecture. It allows many transducers to be arrayed as nodes, on a multi-drop transducer 
network, sharing a common pair of wires. 

IEEE 1451.4 defines a mixed-mode interface for analog transducers with analog and digital operating modes. A 
TEDS was added to a traditional two- wire, constant current excited sensor containing a FET amplifier. The TEDS 
model was also refined to include critical information that must fit in a small memory device, needed by very small 
transducers. Templates are used to describe the data structure of TEDS. The current templates cover accelerometers, 
strain gages, current loop sensors, microphones, thermocouples, and others. 
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Figure 1. IEEE 1451 Family of Standards (Courtesy of Dr. Kang Lee from NIST). 

IEEE PI 45 1.5 defines a transducer- to-NCAP interface and TEDS for wireless transducers. Wireless communication 
protocol standards such as 802.11 (WiFi), 802.15.1 (Bluetooth), 802.15.4 (ZigBee) are being considered as some of 
the physical interfaces for IEEE PI 45 1.5. The objective is to be able to communicate with a wireless transducer 
embodying any of these three wireless protocols. 

IEEE PI 45 1.6 defines a transducer-to-NCAP interface and TEDS using the high-speed CANopen network interface. 
Both intrinsically safe and non-intrinsically safe applications are supported. It defines a mapping of the 1451 TEDS 
to the CANopen dictionary entries as well as communication messages, process data, configuration parameter, and 
diagnosis information. It adopts the CANopen device profile for measuring devices and closed-loop controllers. 


2. OSA-CBM Standard 


The OSA-CBM standard was developed by government and private entities. This standard addresses 
management of health information from any element, subsystem, system, or system-of-systems. The foundation is 
the definition of layers where health information is organized according to the degree of processing, and hence 
amount of DIaK employed, to determine health condition [2, 3]. The standard focuses on automated real-time 
management of health information. In contrast, health management over extended periods of time (non-real time) is 
typically based on large databases, and done primarily by people. This approach is standardized under the Machine 
Information Management Open Standards Alliance (MIMOSA) organization [2]. 
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Figure 2. CBM layered health DIaK architecture. 

3. Machine Information Management Open Standards Alliance (MIMOSA) 

MIMOSA “is a non-profit trade association dedicated to developing and encouraging the adoption of open 
information standards for Operations and Maintenance in manufacturing, fleet, and facility environments. 
MIMOSA’S open standards enable collaborative asset lifecycle management in both commercial and military 
applications.” [2]. 

4. Example Implementation of IEEE 1451 and OSA-CBM Standards 

Figure 3 shows a physical architecture (bus-based, multi drop, Ethernet network) for a pilot ISHM system 
implemented at NASA Kennedy Space Center, Launch Complex 20 (LC-20) [3]. The architecture is hierarchical, 
with buses at various levels, where higher-level information flows up toward the site-wide management computer. 
This is a typical architecture for systems in most industries, including aerospace. Standards were implemented in the 
lower part of the physical architecture (bus showing IEEE 1451.1 and OSA-CBM standards on Ethernet), but it was 
sufficient to demonstrate the impact of standards for ISHM implementation in an operational system, during a test at 
the LC-20. 

The experiment demonstrated interoperability of ISHM systems developed by three different providers: NASA 
Stennis Space Center (NASA SSC), NASA Kennedy Space Center (NASA KSC), and the Pennsylvania State 
University’s Applied Research Laboratory (PSU-ARL). The interoperability was enabled through the use of the 
IEEE 145 1 and OSA-CBM standards. 
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Figure 3. Architecture for pilot ISHM system implemented at NASA Kennedy Space 
Center, Launch Complex 20 (LC-20) showing the use of IEEE 1451.1, OSA-CBM, and 
OSA-EAI standards. 


B. ISHM Knowledge Model (ISHM-DM) 

The concept of an ISHM Domain Model (ISHM-DM) has been introduced previously [4, 5]. ISHM-DM 
embodies DIaK that is needed to achieve ISHM capability; including system element identification and 
specifications, and inter-element relationships used in reasoning approaches. Data is available from sensors and 
components. Distribution of DIaK associated among the physical elements of a system gives rise to an ISHM 
architecture that enables distributed management of DIaK to achieve ISHM functionality. The ISHM architecture is 
a DIaK Architecture (DIaKA), where intelligent processes (e.g. physics-based models) providing various degrees of 
integration (through inter-dependencies) are used to achieve the desired ISHM capability; and where DIaK are 
managed in a distributed manner (Figure 4). This hierarchical architecture enables abstracting models of processes 
occurring throughout the system (e.g. tank pressurization, subsystem leak, valve leak, sensor flat, etc.), and is 
conceptually different from a typical architecture depicting the physical composition of a system, where the 
hierarchy is based on simpler physical elements being assembled into more complex sub-systems and systems. 

Figure 5 is another depiction of the DIaKA. DIaK are distributed among the elements of a system, including 
sensors, actuators, and components; as well as subsystems, and systems. The icons are active repositories of data and 
information pertinent to their function, operation, and health. They also contain process models (knowledge) that 
enable ISHM functionality. Figure 5 shows a representation of the DIakA as it is related to an ISHM-DM of a 
simple rocket test stand system. 
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Figure 4. Data, Information, and Knowledge Architecture for Intelligent ISHM. 



Figure 5. DIaKA showing correspondence with ISHM-DM elements of a small rocket engine test stand. 
Process models are executed often in parallel for consistency checking that leads to anomaly detection and 
reasoning about health of processes, sensors, and components. 

The DIaKA supports the following paradigm. Sensor icons are repositories for sensor processes that operate on 
measurements within a local context, independent of other elements of the system. Sensor processes are, for 
example, algorithms to determine level of noise, changes on level of noise, flat signals, time response characteristics, 
etc. In addition, sensor processes include health assessment processes focused on determining: sensor health, and the 
quality of the measurement. Health assessment sensor processes also receive information from other processes 
higher in the hierarchy to improve their health assessment. For example, a process model of flow from a tank 
through a valve, to atmosphere; can allow consistency checks among pressure and temperature sensors on the tank 
along the path of the flow. If one sensor is inconsistent with the model, this information is fed back to the sensor to 
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improve its own health assessment and anomaly determination. The same applies to component processes. The final 
objective is to determine the health of sensors and components; and do it with maximum utilization of DIaK 
embodied in the various layers of processes in the hierarchy. This approach is described in reference [4]. 

C. Software Capabilities to Develop ISHM Domain Models 

Core capabilities of ISHM include: (1) detect anomalies, (2) diagnose causes, (3) predict future 
anomalies/failures, (4) enable efficient integration and execution of all phases of the life-cycle of a system from a 
systems engineering perspective, and (5) provide the user with an integrated awareness about the condition of 
important elements of the system as a means of guiding user decisions. These capabilities are to provide continuous 
and comprehensive awareness about the health of every element of a system. DIaK must be employed to do the 
reasoning leading to achieving the core capabilities. Furthermore, multiple simultaneous process models and 
approaches should be employed to achieve maximum functional capability level (FCL), that is to make effective use 
of all DIaK embodied in the ISHM-DM. A software system for ISHM capability should support all core capabilities 
by integrating systematically DIaK through the ISHM-DM. The following requirements must be met by the software 
system: 

Object orientation, object representation of system physical elements and associated process models is the best way 
to embed DIaK in a systematic and in an organized manner. Object orientation also embodies re-use of software that 
is modularized into objects, and allows a more intuitive understanding of the code and its outcomes. 

Distribution of ISHM-DM’s within and across networks : ISHM-DM’ s might be distributed among processors 
connected to a network, simply because it is necessary to use parallel processing, and/or ISHM-DM’s might be 
created by different people in various geographic locations. As complexity of systems increase, and/or a large 
number of process models are used in achieving effective ISHM capability, it is not reasonable or manageable to do 
this with a centralized architecture. 

Distribution across processing units : Since multiple process models are expected to be running at any given time, 
the software environments should support parallel processing. 

Inference engine : Many tasks require an inference engine. Reasoning and decision making leading to anomaly 
detection, diagnostics, effects, and prognostics; require contextual integrity and cause-effect analysis using 
heterogeneous data and information. The inference engine must also allow accurate representation and automatic 
execution of failure modes and effects analysis (FMEA). 

Integrated management of distributed DIaK : DIaK must be managed in a way to allow embodiment of systems 
thinking across elements and subsystems. Often this is enabled by definitions of relationships among elements of 
systems that can be physically visible (i.e. attached to, belong to a system); or more abstracted relationships, as it 
relates to involvement in process models (e.g. pressure sensors associated to a particular subsystem, subsystem 
definitions that change with configuration, etc.). 

Definition of dynamic relationships among objects for use in reasoning : Often, the framework for reasoning and 
application of process models changes dynamically with configuration changes, stages of operation, etc. This also 
means that relationships among objects and processes change dynamically, and must be represented in the ISHM- 
DM’s. For example, reasoning to detect leaks in a sealed subsystem requires that membership of elements to sealed 
subsystems must change with valve state changes. 

Iconic representation of systems objects with visible and virtual links (relationships) used to provide intuitive 
representation of reasoning and context The mix of object orientation and iconic representation of DIaK provides 
the ability to intuitively visualize interrelationships and dig deep into details of the ISHM system. As complexity 
increases, graphical programming and visualization become essential. 

A software environment developed by NASA Stennis Space Center and General Atomics [4, 6, 7, and 8] meets 
most of the requirements above. The software was developed using G2 [9], which is a commercial programming 
environment for implementation of intelligent applications. 

D. Intelligent Sensors and Components 

The lower elements in the DIaKA (Figure 5) represent processes associated with sensors and components; where 
“components” is intended to encompass any element that is not a sensor; e.g. tanks, pumps, etc. These elements 
directly represent physical entities in the system; and, in the future, is they are expected to incorporate their own 
embedded processing and networking capabilities. This is already true for sensors, as many “intelligent sensor” 
concepts are now available commercially, and more are in development [10, 11]. 

There are many definitions for “Intelligent Sensor” or IS. The following definition is based on the foundation 
provided by the IEEE 1451 family of standards for Smart Sensors and Actuators. It is reasonable to assume that the 
standard defines a “Smart Sensor (SS),” as described previously in Section A “Standards for ISHM 
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Implementation.” “Intelligent Sensor” is therefore a “Smart Sensor” with the ability to provide the following 
functionality: (1) measurement, (2) measure of the quality of the measurement, and (3) measure of the “health” of 
the sensor. The better the sensor provides functionalities 2 and 3, the more intelligent it is. 

Implementation of IS’s can be done in many ways. Commercial SS incorporating TEDS in-a-chip have been 
available for some time (a web search will reveal many offerings). Some IS or SS modules have been developed in 
industry. These are small format units that incorporate signal conditioning, data acquisition, processing capability, 
and protocols for communicating as network elements [10, 11]. In other cases, IS capability is enabled by a 
combination of hardware and software that turns classic sensors into smart sensors; as is the case with products from 
National Instruments [12]. Intelligent sensor functionality has also been implemented purely in software, again, to 
turn classic sensors into intelligent ones. Figure 6 [6] shows the configuration of a pilot ISHM implementation for a 
rocket engine test stand. Here the Virtual Intelligent Sensor Environment (VISE) turns all non-intelligent test stand 
sensors into intelligent sensors. The VISE publishes IS data and information to a bus for consumption by the ISHM 
system and other users such as repositories and visualization systems. Some of the processes embedded in IS’s 
include: 

• Noise Level Assessment and History Spike Detection and History 

• Flat Signal Detection and History 

• Response Time Characterization 

• Intermittency Characterization and History 

• Physical Detachment Characterization and History 

• Regime Characterization and History 

• Curve Fit on Identified Regimes 



Figure 3. Architecture showing implementation of intelligent sensors through the 
Virtual Intelligent Sensor Environment. 


E. Optimizing sensor selection and placement for ISHM 

When developing an ISHM capability from the ground up, one must optimize sensor suites to achieve maximum 
functional capability (anomaly detection, diagnosis, effects, prognostics). References [13-17) provide context for 
this section. For example, the Systematic Sensor Selection Strategy (S4) is a model-based procedure for 
systematically and quantitatively identifying the sensor compliment that optimally achieves the health assessment 
goals of a system. Properly formulated, an S4 application can be used to determine whether or not existing sensors 
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meet requirements for system health assessment; and, if not, to justify the addition of sensors that allow those 
requirements to be met. As shown in Figure 7, S4 can be logically partitioned into three major elements: the 
Knowledge Base , the Iterative Down-Select Process, and the Final Selection Process. The Knowledge Base consists 
of system design information and heritage experience together with a focus on components with health implications. 
The Iterative Down-Select Process identifies a group or groups of sensors that provide the highest fault detection 
and isolation performance for targeted fault scenarios. This process is further composed of three basic modules: the 
system diagnostic model, the sensor suite merit algorithm, and the down-select algorithm. The result of the Iterative 
Down-Select Process is a single sensor suite with the highest merit algorithm score (i.e., optimal) or a group of 
highest-performing (i.e., nearly-optimal) sensor suites with closely-matched merit algorithm scores. In the final 
selection process, the group of highest performing sensor suites is evaluated using a statistical algorithm that 
provides the final robustness test for each sensor suite. The result of the Final Selection Process is a sensor suite that 
optimally achieves the system health assessment goals. 


Iterative Down -Select Process 
Candidate Sensor Suites 



I Application Specific | Non -Application Specific 


Figure 7. ISHM Sensor Selection Strategy (S4) for optimizing 
sensor selection and placement. 


IV. ISHM in Systems Design, Integration, and Engineering 

Systems Integration and Engineering (SI&E) practices are employed to build complex systems. SI&E for aerospace 
systems has developed into its own discipline, although theories and concepts have not been adequately formalized 
in an academic sense. The role of ISHM in SI&E is linked to the concept of ISHM-DM’s, whereby every element 
that is part of a system comes with its own ISHM-DM that can be rolled-up into an overall system ISHM-DM in a 
plug&play mode. In this sense, as soon as two elements are assembled, the ISHM-DM of each element is 
incorporated into the ISHM-DM of the assembly. In this manner, DIaK compartmentalized in each element becomes 
immediately available to the ISHM-DM of the assembly. Figure 8 shows the concept of systems integration to 
aggregate ISHM-DM’s providing comprehensive and continuous vigilance on the health of the elements throughout 
the integration process. 

The incorporation of ISHM-DM’s as products of the design implies that parts of a system must be accompanied 
by DIaK relevant to determining health of the parts. Failure modes and effects must be captured, as well as 
information such as expected life, specifications, usage, operational environments, etc. 
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Figure 8. ISHM concept for systems integration of ISHM-DM’s 


V. Intelligent Control for ISHM-Enabled Systems 

Control of complex systems that are ISHM-enabled is a nascent area, simply because ISHM itself is also relatively 
new. The objective is for the control function to make use of system health information in order to achieve its 
objectives. Suspect (i.e., disqualified) sensors might removed from use by critical control functions; anomalous 
components might need to be contained so maintain system function; and, in severe cases, new mission objectives 
may need to be identified. The paradigm implies that control systems become users of health information, while at 
the same time making use of actuators to help further improve determination of the system health. This can lead to 
yet another area of control, specifically focused on helping the ISHM capability detect anomalies, diagnose causes, 
and determine effects. An example of a control system that incorporates sensor health information communicated 
using the IEEE 1451.1 Standard is described in reference [18]. 


VI. Opportunities for Advances in Control Verification and Validation Considerations 

This paper describes ISHM capability implementation as purposeful management of DIaK with a focus on 
determining the health of each element in a system. The need to use knowledge, and hence inference engines; and 
the complexities of parallel processing and reconciliation of potentially inconsistent outcomes that lead to anomaly 
determination; requires advances in verification and validation of the ISHM capability itself. This paper only raises 
this issue, but the scope of this topic is broad, and is left for a future discussion. 


VII. Conclusion 

This paper describes concepts, architectures, paradigms, tools, and implementations of ISHM capability. The 
purpose is to show that ISHM capability must be implemented as a Knowledge-based capability, through 
management of data, information, and knowledge (DIaK); whereby “management” implies storage, distribution, 
sharing, maintenance, processing, reasoning, and presentation. The emphasis is also to note that ISHM capability 
increments “intelligence” of the system where it is implemented. We can then talk about ISHM-Enabled systems; 
with a potential to generate significant advances in Systems Design, Integration, and Engineering; as well as in 
Systems Control. The reader should also infer that much work is needed in developing ISHM-DM’s, tools to create 
and use the ISHM-DM’s, implementation of standards for management of DIaK to achieve Plug&Play and 
interoperability. Last, but not least, it is important to note that the ISHM DIaK Architecture (DIaKA) described 
addresses the need for focusing on processes that take place in systems for consistency checking, leading to anomaly 
detection. 


11 

American Institute of Aeronautics and Astronautics 


RELEASED - Printed documents mav be obsolete; validate prior to use. 








Acknowledgements 

The authors would like to thank NASA for providing the opportunity to work on advancing the area of ISHM. 
The authors also express their profound appreciation to the many individuals that through discussions and 
interactions have enriched their understanding of ISHM and made possible this paper. 

Bibliography 

1. http://www.nist.gov/manuscript-publication-search.cfm7pub id=82 1 920 

2. http://www.mimosa.org . 

3. Karl Reichard, Fernando Figueroa, Rebecca Oosdyke, John Schmalzel, and Jose Perotti, “An ISHM Architecture for Ground 

Operations Health Management,” ISHM Conference, Covington Convention Center, KY, Augustl 1-14, 2008. 

4. Figueroa, F., Schmalzal, J., Walker, M., Venkatesh, M., Kapadia, R., “Integrated System Health Management: Foundational 

Concepts, Approach, and Implementation,” AIAA Infotech@Aerospace Conference , 20-22 April 2010. 

5. Figueroa, F., and Schmalzel, J., “Rocket Testing and Integrated System Health Management,” Condition Monitoring and 

Control for Intelligent Manufacturing, edited by L. Wang and R. Gao, Springer Series in Advanced Manufacturing, Springer 
Verlag, UK, 2006, pp. 373-392. 

6. Fernando Figueroa, John Schmalzel, Jonathan Morris, Mark Turowski, and Richard Franzl, “Integrated System Health 

Management: Pilot Operational Implementation in a Rocket Engine Test Stand,” AIAA 2010-3454, AIAA 
Infotech@Aerospace 2010 Conference, 20-22 April 2010, Atlanta, GA. 

7. R. Kapadia, R. Gross, M. Walker, M. Venkatesh. “Health Monitoring Assessment and Prognostics (HealthMAP™) for 

Advanced Arresting Gear System. PHM Society Conference 2009, San Diego, CA, October 2009. 

8. M. Walker, “Model-based Reasoning Applications for Remote Intelligent Systems Health Management”, ASNE Intelligent 

Ships Symposium, May 2007. 

9. http://www.gensym.com . 

10. http://www.eesensors.com/index.html . 

11. http://www.mobitrum.com . 

12. http://www.ni.com . 

13. Melcher, K.J., Sowers, T.J., Maul, W.A, “Meeting the Challenges of Exploration Systems: Health Management Technologies 

for Aerospace Systems with Emphasis on Propulsion,” NASA TM 2005-214026, First International Forum on Integrated 
System Health Engineering and Management in Aerospace , 7-10 November 2005. 

14. Santi, L.M., Sowers, T.S., Aguilar, R.B., “Optimal Sensor Selection for Health Monitoring Systems”, AIAA 2005-4485, 
AIAA 41st Joint Propulsion Conference and Exhibit, 10-13 July 2005. 

15. Maul, W.A., Melcher, K.J., Chicatelli, A.K, and Sowers, T.S., “Sensor Data Qualification for Autonomous Operation of 

Space Systems,” NASA TM 2006-214475, 2006 Fall Symposium Series sponsored by the American Association for 
Artificial Intelligence, 13-15 October 2006. 

16. Melcher, K.J., Fulton, C.E., Maul, W.A., Sowers, T.S., “Development and Application of a Portable Health Algorithms Test 

System,” NASA TM-2007-2 14840, 54th Joint Army-Navy-NASA-Air Force (JANNAF) Propulsion Meeting, 14-17 May 
2007. 

17. Melcher, K.J., Maul, W.A., Futlon, C.F., Wong, E., “Sensor Data Qualification Proof-of-Concept Demonstration,” NASA 

TM-215518, Joint Army-Navy-NASA-Air Force (JANNAF) 6th Modeling & Simulation Subcommittee, 4th Liquid 
Propulsion Subcommittee, 3rd Spacecraft Propulsion Subcommittee Joint Meeting, 8-12 December 2008. 

18. D. Jethwa, R. R. Selmic and F. Figueroa, “Real-time implementation of intelligent actuator control with a transducer health 

monitoring capability,” International Journal of Factory Automation, Robotics, and Soft Computing, no. 1, pp. 5-10, 
January 2009. 


12 

American Institute of Aeronautics and Astronautics 


RELEASED - Printed documents may be obsolete; validate prior to use. 




Integrated Systems Health Management for Intelligent 

Systems $ 


Fernando Figueroa, NASA Stennis Space Center, MS 
Kevin Melcher, NASA Glenn Reseasrch Center, OH 


AIA^ Infotech@Aerospace 
March 29-31, 2011 
Snl.oHis. MO, USA 


Acknowledgements 

The authors would like to thank NASA for 
providing the opportunity to work on advancing 
the area of ISHM. 

The authors also express their profound 
appreciation to the many individuals that, 
through insightful discussions and interactions, 
have enriched their understanding of ISHM. 


Outline 


• Context of the paper. 

• ISHM Definition. 

• ISHM Capability Development. 

- ISHM Knowledge Model. 

- Standards for ISHM Implementation. 

- Software to develop ISHM Domain Models (ISHM- 
DM’s). 

- Intelligent Sensors and Components. 

• Sensor Optimization and Placement for ISHM. 

• ISHM in Systems Design, Engineering, and Integration. 

• Intelligent Control for ISHM-Enabled Systems. 

• Verification and Validation Considerations. 


Context of the Paper 

Intelligent System: Manages data, information, and knowledge 
(DlaK) to achieve its mission (Manage: storage, distribution, sharing, 
maintenance, processing, reasoning, and presentation) 

An attribute or quality of intelligent systems should be to 
posses a health management capability that: 

- Employs knowledge about the system embodying “systems 
thinking” (captures interactions among elements of the system). 

- Is continuously vigilant. 

- Is comprehensive in assessing health of each element of a 
system. 

- Is systematically evolutionary to achieve higher and higher 
functional capability levels (increasing effectiveness). 

In order to make this capability possible, the health 
management system needs to incorporate “intelligence.” 


ISHM Definition 


Its own discipline, or sub-discipline under Aerospace 
Systems Design, Engineering, and Integration. 

Management of data, information, and knowledge (DlaK) 
with the purposeful objective of determining the health of 
a system (Management: storage, distribution, sharing, 
maintenance, processing, reasoning, and presentation). 

ISHM is akin to having a broad-base team of experts 
who are all individually and collectively observing and 
analyzing a complex system, and communicating 
effectively with each other in order to arrive at an 
accurate and reliable assessment of its health. 
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Determination of Health 


Use available SYSTEM-WIDE data, information, and knowledge (DlaK) to 

- Identify system state. 

- Detect anomaly indicators. 

- Determine and confirm anomalies. 

- Diagnose causes and determine effects. 

- Predict future anomalies. 

- Recommend timely mitigation steps. 

- Evolve to incorporate new knowledge. 

- Enable integrated system awareness by the user (make available relevant 
information when needed and allow to dig deeper for details). 

- Manage health information (e.g. anomalies, redlines). 

- Capture and manage usage information (e.g. thermal cycles). 

- Capture and manage design life and maintenance schedule. 

- Enable automated configuration. 

- Implement automated and comprehensive data analysis. 

- Provide verification of consistency among system states and procedures. 


ISHM Capability Development 
ISHM Knowledge Model 

A plethora of Data, Information, and 
Knowledge (DlaK) must be applied to 
achieve high functional capability level 
(FCL) health management. 

The ISHM Domain Model (ISHM-DM) 
encompasses DlaK and the tools to 
implement ISHM capability. 


ISHM Capability Development 
ISHM Knowledge Architecture 

DlaK in the ISHM-DM are associated with software 
objects that represent process models that take place in 
objects and/or collections of objects that encompass a 
system of interest. 

Process models are organized as objects in a 
hierarchical network (ISHM DlaK Architecture), to reflect 
levels of complexity as processes take place involving 
single elements, subsystems, or the entire system. 

- Local processes using local DlaK are at the bottom of the 
hierarchy. 

- Processes using increasing DlaK occupy higher levels in the 
network. 
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ISHM Capability Development 
Standards for ISHM 

• IEEE 1451 Family of Standards for Smart Sensors and 
Actuators. Lead by NIST (Dr. Kang Lee). 

• OSA-CBM (Open Systems Architecture for Condition 
Based Maintenance). Developed by industry and 
government, and transferred to the MIMOSA (Machine 
Information Management Open Standards Alliance) 
organization. 

• OSA-EIA (Open Systems Architecture for Enterprise 
Application Integration). MIMOSA organization. 


ISHM capability must integrate DlaK across physical, virtual, and discipline 
boundaries. This is not possible in an affordable manner unless standards are used 
to achieve plug&play and interoperability. 



ISHM Capability Development 
Standards for ISHM 


IEEE 1451 Family of Standards 

(supporting different physical interfaces and configurations) 



Kang Lee/NIST/March 2011 



ISHM Capability Development 
Standards for ISHM 
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ISHM Capability Development 
Standards for ISHM 


Site-wide OSA-EAI Element 



Architecture for pilot ISHM system implemented at NASA Kennedy Space Center, Launch 
Complex 20 (LC-20) showing the use of IEEE 1451.1, OSA-CBM, and OSA-EAI standards 










Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Object orientation: object representation of system 
physical elements and associated process models is the 
best way to embed DlaK in a systematic and in an 
organized manner. 

• Distribution of ISHM-DM’s within and across 
networks : ISHM-DM’s might be distributed among 
processors connected to a network, simply because it is 
necessary to use parallel processing, and/or ISHM-DM’s 
might be created by different people in various 
geographic locations 


Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Distribution across processing units: Since multiple 
process models are expected to be running at any given 
time, the software environments should support parallel 
processing. 

• Inference engine: Many tasks require an inference 
engine. Reasoning and decision making leading to 
anomaly detection, diagnostics, effects, and prognostics; 
require contextual integrity and cause-effect analysis 
using heterogeneous data and information. 


Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 

capabilities by integrating systematically DlaK through the ISHM-DM 

• Integrated management of distributed DlaK: DlaK must be 
managed in a way to allow embodiment of systems thinking across 
elements and subsystems. Often this is enabled by definitions of 
relationships among elements of systems that can be physically 
visible (i.e. attached to, belong to a system); or more abstracted 
relationships, as it relates to involvement by groups of objects in 
process models. 

• Definition of dynamic relationships among objects for use in 
reasoning : Often, the framework for reasoning and application of 
process models changes dynamically with configuration changes, 
stages of operation, etc. 


Software to develop ISHM 
Domain Models (ISHM-DM’s) 

A software system for ISHM capability should support all core 
capabilities by integrating systematically DlaK through the ISHM-DM 

• Iconic representation of systems objects with visible and 
virtual links (relationships) used to provide intuitive 
representation of reasoning and context The mix of object 
orientation and iconic representation of DlaK provides the ability to 
intuitively visualize interrelationships and dig deep into details of the 
ISHM system. As complexity increases, graphical programming and 
visualization become essential. 
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ISHM Capability Development 

Intelligent Sensors and Components 

Smart Sensor/Actuator (NIST) 

“The IEEE (Institute of Electrical and Electronics Engineers) 1451 smart transducer 
interface standards provide the common interface and enabling technology for the 
connectivity of transducers to microprocessors, control and field networks, and data 
acquisition and instrumentation systems. The standardized TEDS specified by IEEE 
1451.2 allows the self-description of sensors and the interfaces provide a 
standardized mechanism to facilitate the plug and play of sensors to networks. The 
network-independent smart transducer object model defined by IEEE 1451.1 allows 
sensor manufacturers to support multiple networks and protocols. Thus, transducer- 
to-network interoperability is on the horizon. The inclusion of PI 451. 3 and PI 451. 4 to 
the family of 1451 standards will meet the needs of the analog transducer users for 
high-speed applications. In the long run, transducer vendors and users, system 
integrators and network providers can all benefit from the IEEE 1451 interface 
standards [1].”. 


“Intelligent Sensor” is a “Smart Sensor” with the ability to provide the following 
functionality: (1) measurement, (2) measure of the quality of the measurement, and 
(3) measure of the “health” of the sensor. The better the sensor provides 
functionalities 2 and 3, the more intelligent it is. 



ISHM Capability Development 

Intelligent Sensors and Components 

Typical Process Models for Sensors 

• Noise Level Assessment and History 

• Spike Detection and History 

• Flat Signal Detection and History 

• Response Time Characterization 

• Intermittency Characterization and History 

• Physical Detachment Characterization and History 

• Regime Characterization and History 

• Curve Fit on Identified Regimes 


“Intelligent Sensor” is a “Smart Sensor” with the ability to provide the following 
functionality: (1) measurement, (2) measure of the quality of the measurement, and 
(3) measure of the “health” of the sensor. The better the sensor provides 
functionalities 2 and 3, the more intelligent it is. 



ISHM Capability Development 

Intelligent Sensors and Components 


Example Intelligent Sensor Implementations 



The Virtual Intelligent Sensor Environment (VISE) converts all classic 
sensors installed in a rocket engine test stand into “intelligent sensors.” 
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Example Intelligent Sensor Implementations 
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Sensor selection and Placement 

for ISHM 

When developing an ISHM capability from the ground 
up, one must optimize sensor suites to achieve 
maximum functional capability (anomaly detection, 
diagnosis, effects, prognostics). 


Sensor selection and Placement 

for ISHM 

Systematic Sensor Selection Strategy (S4) is a model-based procedure for systematically 
and quantitatively identifying the sensor compliment that optimally achieves the 
health assessment goals of a system (Reference 14 of the paper). 
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ISHM in Systems Design, 
Integration, and Engineering (SDI&E) 

SDI&E practices are employed to build complex 
systems. 

SDI&E for aerospace systems has developed into its own discipline, 
although theories and concepts have not been adequately 
formalized in an academic sense. 

The role of ISHM in SDI&E is linked to the concept of ISHM-DM’s, 
whereby every element that is part of a system comes with its own 
ISHM-DM that can be rolled-up into an overall system ISHM-DM in a 
plug&play approach. 

When two elements are assembled, the ISHM-DM of each element 
is incorporated into the ISHM-DM of the assembly. In this manner, 
DlaK compartmentalized in each element becomes immediately 
available and useful to the ISHM-DM of the assembly. 


ISHM in Systems Design, 
Integration, and Engineering (SDI&E) 
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Intelligent Control for ISHM-Enabled 

Systems 

• Control of complex systems that are ISHM-enabled is a 
nascent area, simply because ISHM itself is also 
relatively new. 

• The objective is for the control function to make use of 
system health information in order to achieve its 
objectives. 


The paradigm implies that control systems become users of health 
information, while at the same time making use of actuators to help 
further improve determination of the system health 



Intelligent Control for ISHM-Enabled 

Systems 

Example Application (Reference 18 of the paper) 
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Verification and Validation 
Considerations for ISHM 


The need to use knowledge, and hence inference engines; 
and the complexities of parallel processing and 
reconciliation of potentially inconsistent outcomes that 
lead to anomaly determination; requires advances in 
verification and validation of the ISHM capability itself 


Backup Slides 


Health Assessment Database System 

HADS 


• Health Electronic Data Sheets (HEDS) 

• Repository of anomalies and algorithms 



Transducer Electronic Data Sheets (TEDS) 
Historical test data and analysis results 


ISHM (G2) 


Virtual Intelligent 
Sensor Environment 
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Health Assessment 
Database System 
(HADS) 


HADS Browser 
Application 




HADS Browser Application 

HADS Browser Capabilities 

• Allows longitudinal analyses and comparisons with previous test results 

• Viewing usage statistics on monitored elements 

- cycle times on valves 

- mean time to failure 

• Viewing anomalous events/data trends 

• Viewing TEDS 
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CSG ISHM Domain Model: 

Top Layer View 


ISHM Domain 
Model 
Top Layer 
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CSG ISHM Domain Model: 

Transducer Data Plots 


% Telewindows Client 
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Streaming data plots 
from selected sensors 
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CSG Anomalies Detected 
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Test 21 A: TC-14A4194-S Anomaly Report 
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Transducer Anomaly Report Graphs for one sensor in four consecutive tests. 




Elements of an ISHM System: 

ISHM Model - Proximate Cause Analysis 





Expanded causa I -directed graph generated by the 
detection of a leak in the subsystem where a valve was 

opened manually (injected leak) 
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List of Anomaly Detection 

Capabilities 


Anomaly/Behavior 

Demonstrated Cause 

Detection Approach 

Leaks (pipes, valves, etc.) 

Various 

Checking for pressure leaks using the concept 
of Pressure Subsystems. 

Valve state undetermined 

Defective feedback sensor 
Controller failure 

Determines valve state by checking 
consistency of command, feedback, 
open/close switches, and pressure conditions 
upstream and downstream. 

Valve oscillation 

Fluid contamination in hydraulic 
supply 

Compare running standard deviation of 
command versus feedback. 

Valve stuck 

Fluid contamination in hydraulic 
supply 

Seat seizure 

Feedback remains horizontal while command 
changes. 

Excessive noise, spikes, etc. 

Interference 

Running standard deviation exceeds set limits. 
Thresholds violations during short time spans 
(compared to sensor time-constant). 

Degradation 

Wear, aging 

Trend detection using curve fitting and 
determination of time-constants. 

Prediction-Measurement 

mismatch 

Various 

Use predictive model (e.g. from Modeling & 
Analysis Group) to predict sensor values and 
compare with measurements. 



Short-Time Fourier Transform 

Segmentation 

Figure 1. Simulated input signal 



Figure 2. short time FT 9s window 



80 0 time 

frequency 



Determining Valve-State 
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Checking for Pressure Leaks 




Runtime Predictive Modeling 
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Intelligent Sensors 


• Smart sensor 

- NCAP (Go Active, Announce) 

- Publish data 

- Set/Get TEDS 

• Intelligent sensor 

- Set/Get HEDS 

- Publish health 

• Detect classes of anomalies using: 

- Using statistical measures 

• Mean 

• Standard deviation 

• RMS 

- Polynomial fits 

- Derivatives (1 st , 2 nd ) 

- Filtering — e.g., Butterworth HP 

- FFT — e.g., 64-point 

- Wavelet Transforms (segmentation) 

- Algorithms for 

- Flat 

- Impulsive (“spike”) noise 

- White noise 

- Other (ANN, etc.) 






Intelligent Sensors have 
embedded ISHM 
functionality and support 
Smart Sensor standards 



Classic architecture describing 
how systems are built 
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Systems 
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